Ëùôôóöøøòò Éùù Òò Öøý Çêêê Áòøöó×ô Blockinøøóò Òò Ååòòôùððøøóò

Large s ale system development and maintenan e proje ts often need to build s a olding|tools that help build the target system|that is ustomized to the proje t. For some lasses of tools, the ost barrier is too high to onsider implementing ustomized support that might be bene ial to the proje t, and thus the proje t makes do with whatever o -the-shelf support is available. Run-time monitoring and manipulation tools are one su h ategory. This paper presents a framework design and protoype implementation of generi support for high-level, exible, and programmable introspe tion and manipulation of CORBAbased appli ations. This type of support an be an e e tive aid in maintaining existing CORBA omponents as they evolve throughout the system life y le. Introspe tion allows system engineers to observe the dynami behavior to better understand how to integrate omponents together, and manipulation allows them to \glue" omponents together that have slightly di erent expe tations of their intera tion. Our framework implementation is being a omplished by tying a new CORBA dynami a ess feature known as Portable Inter eptors with an existing very high level programming language, T l/Tk. 1 1 Introdu tion Many system development and maintenan e a tivities need or an bene t from introspe tive and manipulative apabilities in a running system. By this we mean the ability to peer into a running system and observe it, and even manipulate it to some extent. Su h abilities have run the gamut from simple tra ing fa ilities (even the lowly printf()!) to full single-step debugging ontrol. In omponent-based systems, espe ially distributed ones su h as CORBA, dire ted instrospe tion and manipulation an be of extra bene t. In these situations, introspe tive apabilities su h as he king pre onditions and post onditions on omponent interfa es an be helpful in ensuring that the omponent is being used properly, and that it is meeting the demands expe ted of it. Manipulative apabilities may also be needed, su h as mapping a all of one form into a all that mat hes what a re-used omponent expe ts. This is typi ally done with wrappers, but might also be done by meta-level manipulative apabilities. The omponent frameworks themselves an help or hinder the provision of these features. Many other uses for introspe tion and manipulation exist, from debugging and pro ling to redire ting invo ations to spe i versions or even mapping a single all to multiple omponent versions for fault toleran e and reliability [2℄. Some of these uses are general, but many are often very spe i to a parti ular appli ation. Be ause the e ort in building introspe tion and manipulation tools is very high, proje ts are often prevented from building appli ation-spe i tools or rapidly prototyping new general-purpose tools. It would seem natural to provide some generi and easy-to-use me hanism to support these needs, and that is pre isely the point of the work des ribed here. In this paper we fo us on CORBA-based systems, though our methods ould also be applied to other domains, and we are a tively doing so. In the most re ent versions of CORBA a me hanism exists to support obje t invo ation introspe tion and redire tion, whi h is the Portable Inter eptor spe i ation [10℄. This spe i ation details a ommon API and me hanism for programming CORBA message inter eptors, whi h allow the apture and inspe tion of obje t invo ations and replies, events, and ex eptions. It also allows obje t invo ations to be redire ted from the original target obje t to a di erent obje t. With this foundation, it is possible to build introspe tive and manipulative apabilities in an ORB-neutral way, paving the way for new development tools. However, the inter eptor spe i ation leaves mu h hard, low-level programming to the tool developer, and gives no exibility or end-user programming apability. To this end, our vision is to provide a exible, easy-to-use me hanism for introspe tion and manipulation that allows not just omplex tools to be developed but allows the CORBA appli ation programmers to easily build one-o tools that meet a spe i need at a spe i time. Rather than try to pre-de ne the apabilities we think might be needed, a better approa h to a hieve this end is to re-use one of the many s ripting languages that are available. S ripting languages allow extremely rapid development of fun tionality, at the the ost of speed sin e they are interpreted languages. But sin e they are full programming languages, there is no limit on the type of tools that might be built using them. In some sense, s ripting languages have 1 overpowered any potential wide-spread a eptan e of domain-spe i languages, and are ideal for building the s a olding type of software tools that must be built to help manage, test, observe, and maintain a large produ tion software system. We hose the T l/Tk s ripting language for our framework, be ause of its lean design, ease of integration with traditional programming languages (C/C++), and GUI apabilities. However, the prin iples underlying our approa h an be applied with other languages. In this paper we des ribe the design of our generi CORBA introspe tion and manipulation framework, alled Orbish1 give examples of its use, and detail ongoing and future work. Se tion 2 of this paper details ba kground in development tools, CORBA, and T l/Tk. Se tion 3 then presents the detail of the Orbish framework. Se tion 4 des ribes its present status and gives examples, Se tion 5 dis usses related work, and Se tion 6 on ludes with lessons and dire tions for future work. 2 Ba kground To understand the ontext for this work, we present some ba kground on program monitoring, CORBA, and the T l programming language. 2.1 Introspe tion, Monitoring, and Manipulation Viewing, understanding, and ontrolling the dynami behavior of programs have been issues ever sin e the rst program needed to be debugged. Traditional program introspe tion has been done with a debugger, aided by a ompiler that an in lude symbol and sour e le information in the exe utable, and by hardware-assisted breakpointing apability. This approa h an be too intrusive if one needs to monitor a program with as little e e t as possible on the behavior, espe ially on the timing behavior. Thus, other e orts at minimal intrusion are often explored, and these e orts are often parti ular to the programming language or framework te hnology in use. Introspe tion is a powerful meta-programming feature that enables dynami ity in software programs. This dynami ity an be used by the program itself as a me hanism to dis over and utilize new or di erent omponents, or it an be used by tools and frameworks to ontrol the appli ation for purposes of debugging, monitoring, or evaluation, and for building transparent servi es for distribution, fault toleran e, quality of servi e me hanisms, and other su h non-fun tional needs (e.g. [12℄). Re e tion apability was also a ne essary ondition to the onstru tion of real implementations of the ideas behind software ar hite ture and ar hite ture des ription languages, and most importantly behind those that allowed dynami re on guration. In all of these ases, it is useful to onsider the fundamental introspe tive apabilities of the underlying foundation, whether it is Java, CORBA, LISP, or dynami -link libraries, as the lowest level, \primitive" operations, and then design and onstru t higher layers of abstra tion that embody the fun tionality needed by a spe i appli ation of introspe tion. Thus, the Java Re e tion 1ORB Inter eptor Shell, where shell is the traditional term for the interpreter of the s ripting language. 2 API is used to great advantage in the JavaBeans framework, whi h provides high-level apabilities for dynami , selfon guring appli ations [6℄. Interpreted languages, even byteode interpreted ones su h as Java, traditionally go well beyond ompiled languages in terms of their introspe tion apability. This is natural in the sense that they usually already have the meta-information anyways (where it an be ompiled away in ompiled languages), and the users of these languages tend to desire the dynami manipulation apability. In this paper, our fo us is on the introspe tion of ompiled (C++) CORBA appli ations, for the uses of tools and frameworks rather than dynami appli ations. In this ase, we su er the ills of ompiled languages, where meta-information often does not exist, but bene t from the CORBA infrastru ture, whi h re-introdu es mu h of that meta-information for its own purposes of managing the distributed obje ts it is servi ing ommuni ation for. However, as will be seen in this paper, the low-level apabilities in CORBA were not always designed with a vision for all the possible uses that some introspe tive apability might enable. A more in-depth presentation of related work is in Se tion 5. 2.2 CORBA The CORBA (Common Obje t Request Broker Ar hite ture) standard has de ned rossplatform remote obje t invo ation for ten years now [11℄, and it is heading towards its se ond major revision, CORBA 3.0. From early on CORBA had a proposed spe i ation for obje t request inter eptors, but it was in omplete and optional. Coin ident with version 2.4.2 and later versions, a new inter eptor spe i ation was drafted, known as Portable Inter eptors [10℄. Before this, vendors had followed more or less the suggested inter eptor me hanisms, and provided their own vendor-spe i enhan ements where needed. This was quite natural be ause real programs needed to be debugged, of ourse, and they ould not wait for a omplete standard! Examples of these are Iona's Orbix Filters and SmartProxies, des ribed in more detail in Se tion 5. With the Portable Inter eptor standard, it is now possible to reate debugging, monitoring, and other introspe tion tools that will interoperate with any vendor ORB that supports them, whi h will soon be the majority of ORBs. Unfortunately, this inter eptor standard does not allow for the manipulation of obje t invo ation messages, or for the manipulation of the CORBA obje ts themselves. The most that the inter eptor standard supports is the redire tion of an obje t invo ation away from the target obje t and to a di erent obje t, or the throwing of a CORBA ex eption. 2.3 T l/Tk T l (Tool Command Language [13℄, pronoun ed \ti kle") is a programming language in the lass known as \s ripting" languages, a moniker derived from the programmati interfa e to the original Unix shells (e.g., sh, sh) for whi h \shell s ripts" were written. Newer s ripting languages su h as T l, Perl, Python, and PHP are mu h more advan ed than the old shell s ripting languages, yet they retain the ease of use and the apability for extremely rapid development of advan ed fun tionality. T l has evolved oin ident with a graphi al user interfa e toolkit known as Tk, and together they reate a platform for the easy reation of intera tive programs. 3 T l has always supported a lean interfa e with the C programming language, sin e it was originally developed to be embedded into VLSI design tools. T l an be both easily exe uted from C/C++ and extended with ustom ommands written in C/C++. It is rather misleading to all these languages \s ripting" languages, in that they are very powerful interpreted languages, with built-in data stru tures su h as lists and asso iative arrays (di tionaries). Some have inherent database apabilities, while others provide it through add-ons. Most have fun tional programming language onstru ts; for example, T l treats ode as data, has an eval ommand, and an reate and use lambda fun tions. Modules provide anned support for web servi es, GUI interfa es, email, ftp, en ryption, and many other high-level abstra tions. The upside of s ripting languages is that while a ademi omputer s ien e has not seemed to know what to do with them, they have made a tremendous impa t in pra ti e, and an be found running mu h of the web servi es we use every day, to being the foundations of test harnesses, rapid prototyping environments, and many other real world situations. The downside to most s ripting languages is that they do not have a formal semanti s but rather an operational one, whi h an hange based on the version of the interpreter one is running! They are targeted towards a hieving pra ti al usefulness, not theoreti al semanti orre tness. However, lose inspe tion of ompiled languages often reveals similar ambiguities [4℄. 3 Methods It should be lear from the ba kground that ombining CORBA Portable Inter eptors with a s ripting language su h as T l will provide a powerful platform for not only the rapid development or prototyping of tools but for the ability of the appli ation developer to easily develop their own spe ial-purpose tools targetted for their parti ular system and proje t needs. A major goal of our framework is that it be easily usable by a tool or appli ation developer. While the main aspe t of this is aptured in the integration of a s ripting language into the introspe tion and manipulation framework, it is also the ase that the framework itself should be easily deployable. Thus, we would like the inter eptor framework to be \plug and play". This means that: No hanges to the ORB ode should be ne essary. Indeed, many appli ation developers will not have the apability to re ompile the ORB, it being provided in the form of libraries and binaries from ommer ial vendors. No or few sour e ode hanges in the appli ation should need to be made to use it. Intrusion should be restri ted to initialization alls. Typi ally, ORBs are at least partially in the form of library ode that needs linked to the appli ation ode to reate an exe utable CORBA lient or server. In these ases, ompile and runtime options ontrol how the ORB is on gured, in luding whether inter eptors are enabled or not2. Our goal 2Optional apabilities are often bypassed with ompile-time swit hes in order to produ e eÆ ient exe ution when those options are not needed. 4 Tcl/Tk Interpreter Portable Interceptor CORBA ORB Server Objects CORBA Manipulation Object reply invocation User−Level Tcl program Figure 1: The orbish ar hite ture. is that there be no appli ation ode hanges in order for our framework to be deployed, although ompile time options and additional library linking may be needed. Unfortunately, it seems that the Portable Inter eptor spe i ation does not mandate a standard built-in me hanism for automati ally installing and initializing an inter eptor, otherwise we ould have avoided any intrusion into the appli ation ode. We instead a ept a slight intrusion into the appli ations startup ode to initialize an inter eptor. However, it is a ode template that an simply be in luded as is, and ompiled in or out using C #de ne's. Later, in des ribing the detailed design, we will see another intrusion where threading and event loops are onsidered, but this is still in the form of a ode template. 3.1 Overall Ar hite ture Figure 1 depi ts the overall ar hite ture of our system. A CORBA ORB is a manager and request deliverer that manages CORBA obje ts and delivers requests and replies to and from them. The gure and the following text des ribe the ar hite ture on the server side of a CORBA program. The lient side is analogous, with the requests and replies in the opposite dire tions. The Portable Inter eptor interfa e standard de nes a low-level C++ interfa e from whi h the developer implements the inter eptor. We add a thin layer atta hed to this interfa e whi h translates the inter eption into a T l fun tion invo ation and data des ribing the inter epted message. After inter eption is done with the message the ORB then sends it on to the obje t it was intended for, or to the obje t it was forwarded to. After the target obje t handles it and generates a reply, the reply is also inter epted, pro essed by the T l program, and only then is it sent ba k to the lient who made the original request. Thus, simply by writing T l ode, a developer an monitor the invo ations of CORBA obje ts, and an do so in an easily ustomizable yet fully omputational environment. If they need to perform omplex omputation pro essing to he k assertion-type onditions over the invo ation 5 values, even a umulating omputations over multiple invo ations, this is easily done in the T l environment. No onstrained assertion language is in the way to stop them. A GUI interfa e an easily be atta hed to the T l inter eptor that an, for example, provide visual monitoring information to a developer while the system under test is running. As mentioned before, this message path through the inter eptor and the user-level T l ode is mostly of introspe tive value only. The inter eptors an see the message and its arguments, and the reply with its arguments, but annot manipulate these values at all. The only manipulation point available to an inter eptor is that of redire ting the obje t invo ation to another target obje t. While it is understandable that the standard spe i ers would be leary of allowing un ontrolled manipulation, it is our opinion that while a system is under development or maintenan e, the developers ought to be free to inspe t and modify the runtime environment, whether to produ e test ases that annot be produ ed by \ orre t" behavior or to prototype possible hanges to appli ation behavior. Thus we are motivated to provide additional manipulation inter eption points. How this is done is detailed in Se tion 3.3. 3.2 Detailed Design The CORBA Portable Inter eptor (PI) spe i ation provides individual hooks for ea h of the CORBA message types that are possible. The inter eption points are named di erently but symmetri ally on the lient and server sides. The server side PI inter eption points are: re eive request servi e ontexts is the point where a CORBA method invo ation is rst inter epted. At this point the obje t and method that is being invoked are available, but not the a tual method arguments. re eive request is the point where the a tual method all is inter epted, and it in ludes the arguments for this spe i method all. Only the CORBA in and inout arguments are available. send reply is the point where a method all's return value is inter epted before it is sent to the lient who initiated the request. Not only is a return value available, but also any inout and out parameter values. send ex eption is the inter eption point for ex eptional rather than normal returns. send other is the inter eption point for non-normal returns that are not lassi ed as de ned ex eptions. The lient side PI inter eption points are: send request is the point where the a tual method all is inter epted before it is sent to the server, and it in ludes the arguments for this spe i method all. Only the CORBA in and inout arguments are available. 6 send poll is the point where an asyn hronous method all is inter epted, and it in ludes the arguments for this spe i method all. Only the CORBA in and inout arguments are available. re eive reply is the point where a method all's return value is inter epted. Not only is a return value available, but also any inout and out parameter values. re eive ex eption is the inter eption point for ex eptional rather than normal returns. re eive other is the inter eption point for non-normal returns that are not lassi ed as de ned ex eptions. Our design in T l mirrors the inter eption points in the CORBA Portable Inter eptors, along with our two additional server-side points that provide modi ation a ess to the arguments and return values:3 re eive request rw is our server-side non-PI point where we allow the method arguments to be manipulated. Only the CORBA in and inout arguments are available. send reply rw is our server-side non-PI point where a method's return value an be manipulated. For the Orbish T l inter eptor interfa e (PI and non-PI), we use T l pro edures named the same as ea h inter eption point, and invoke that pro edure at the orresponding inter eption point. The T l program, then, is rea tive in regards to ontrol ow, it being quies ent until an inter eption point is invoked. Yet the T l interpreter maintains the program state between these points, so persistent data is available for a umulating omputational results. In terms of making the data des ribing the inter epted message available to the T l, before alling the appropriate T l pro edure we pro ess the ORB-provided inter eption data on the C++ side and instantiate several T l variables with values from this data. This means that by the time the pro edure is run, there are T l variables that have the data. A hoi e had to be made as to whether the T l variables should be parameters to the invoked pro edure or be global variables available to the whole program. We hose to make them global variables be ause in general they will be useful at other inter eption points as well, and this avoids for ing an inter eption pro edure to opy them to a global variable if indeed they were to be used at another inter eption point. Using global variables is not as bad as it sounds, however, be ause T l has modules alled namespa es whi h modularize the global namespa e and limit the s ope of global (i.e., persistent) data. Our design de nes a new namespa e CorbaInter ept in whi h all pro edures and variables exist. Spe i ally, the namespa e spe i ation is shown in Figure 2. The lient and server inter eption points and data variables are wrapped into the same namespa e be ause it is often the ase that a single exe uting ORB will have lient and server obje ts 3As far as we an tell, there is no dire t way to implement portable ustomized lient-side modi ation inter eption points, and thus we only add server-side points. 7 namespa e eval CorbaInter ept { # All potential server and lient # inter eption points namespa e export # server in oming inter eptions re eive_request_servi e_ ontexts re eive_request re eive_request_rw # server outgoing inter eptions send_reply send_reply_rw send_ex eption send_other # lient outgoing inter eptions send_request send_poll # lient in oming inter eptions re eive_reply re eive_ex eption re eive_other # module onstru tor and destru tor initialize finalize # Client and Target Available Data # at re eive_request_servi e_ ontexts # and send_request variable TargetClass TargetMethod TargetIOR ClientIOR # Method invo ation arguments available # at re eive_request and send_request variable MethodInArgsCount variable MethodInArgsTypes ;# list variable MethodInArgsModes ;# list variable MethodInArgs ;# list # Method result(s) available at send_reply # and re eive_reply variable MethodOutArgsCount variable MethodOutArgsTypes ;# list variable MethodOutArgsModes ;# list variable MethodOutArgs ;# list variable MethodResultType variable MethodResult } Figure 2: Orbish T l inter eptor interfa e spe i ation. 8 running on it. Additionally, we have added initialization and nalization points for any ode that might have to be run rst or last. One primary use of initialization will be to onstru t a GUI display for a tool based on our framework. A di erent design hoi e ould have been made|for instan e, reating a di erent T l intereption point for ea h ORB-managed obje t. This might have provided elegant obje t-spe i introspe tion fun tionality to be reated. However, it would hinder the generi types of introspe tion that are needed in building broadly appli able tools, and more importantly would violate the existing ar hite tural design of the inter eptors, whi h is a single inter eption point per message intera tion point. This design still allows per-obje t ustomization to be done, be ause the CORBA inter eption data in ludes the obje t IOR (Interoperable Obje t Request ID), whi h identi es the target (or lient) obje t. Thus, the inter eption ode an invoke spe i fun tionality based on obje t identity. 3.3 Manipulation from T l Thus far, the T l interfa e and des ription have fo ussed on the introspe tion apability. While this alone is very useful for many tools, we would like manipulative apability as well. Ultimately, our goal is to o er powerful manipulative ontrol over the CORBA invo ation. This in ludes modifying the arguments or return value(s), translating the invo ation to satisfy the interfa e of an un hangeable reused omponent, and enabling fault tolerant apability su h as the ability to invoke multiple obje t versions from one invo ation and manage the multiple results. The subje t of this paper, however, restri ts manipulation to just being able to modify the in oming arguments and the outgoing return values (and output arguments). Our approa h is to build spe ial-purpose CORBA target obje ts that will invoke manipulationapable T l inter eption points on the messages, then invoke the original target obje t, and return the (possibly manipulated) reply. This will integrate the inter eption apability with manipulative apability, and provide a seamless me hanism for both, namely a T l program. CORBA de nes a method for redire ting an obje t invo ation to another obje t, namely a \forward" ex eption, whi h in ludes the identity of the obje t to whi h the invo ation is forwarded to. We take advantage of this by forwarding the invo ations to our own server obje t that implements the T l manipulation inter eption points (re eive request rw and send reply rw). This obje t then invokes the original target obje t. The me hanism for setting up this forwarding apability is the CORBA POA (Portable Obje t Adaptor) and its poli y-based intera tion with the Servant Loator, an obje t identi ation servi e. Our use of the Servant Lo ator does not interfere with an appli ation's potential use of the same CORBA apabilities. This target obje t invo ation is done through DII, the Dynami Invo ation Interfa e, a CORBA fa ility that allows a CORBA obje t invo ation to be reated dynami ally rather than at a stati , ompiled all site (as is usual). This allows the manipulation apability to be built into a generi CORBA obje t, and not need to be ustomized for ea h appli ation. Be ause the two manipulationapable inter eption points have to be provided for with more overhead than the PI-based \read-only" inter eption points, we made these optional. This 9 an be ontrolled at run-time ompletely within the T l inter eption ode. In the PI reeive request servi e ontext point, whi h is the rst inter eption point for an invo ation, the T l ode an set a variable in the CorbaInter ept namespa e alled \EnableRWInter eption", whi h then informs the Servant Lo ator to forward the invo ation to the manipulation obje t. Thus, both introspe tion and manipulation an be built into CORBA generi ally, and a essed programmati ally through the T l s ripting language, and ontrol over the extra overhead of manipulation is entirely within the high-level T l ode. 3.4 T l Control Issues We have presented a view of the ORB in ontrol and only invoking the T l program when inter eption of messages o urs. This simple view leaves the CORBA ORB in omplete ontrol and only invokes any T l ode when an inter eption a tually takes pla e. However, one advantage of T l is that it supports the Tk GUI toolkit, whi h allows intera tive programs to be written. We envision user-intera tive tools to be written on top of our framework, and thus the T l program must be able to rea t to both CORBA inter eptions and to user requests. An obvious hoi e might be to make the T l program be a separate heavyweight pro ess, and simply send ommands ba k and forth between the CORBA ORB pro ess and the T l pro ess. This solution entails too mu h overhead for the simpler ases when the T l program does not have a user interfa e and should be monitoring the CORBA program with as little overhead as possible. Another approa h would be to require a separate thread for the T l program, thus separating it from the ORB thread(s). In theory this is lean, but in pra ti e this is messy be ause the various ORB vendors may or may not support the various thread pa kages. Trying to ombine and reuse omponents that make di erent assumptions about threading is extremely diÆ ult and is an example of the ar hite tural mismat h problem of omponent reuse [5℄. A problem that was en ountered with using the threaded model is that T l is only threadsafe per interpreter. What this means is that a multi-threaded program that embeds T l an run multiple interpreters in di erent threads (and running possibly di erent T l programs), but a given running T l interpreter (i.e., program) should be a essed by only one thread. Thus, we ould not allow a GUI intera tion thread exe uting the T l ode from the GUI events end to oexist with the ORB thread that invokes the inter eption points and thus the T l inter eption pro edures. Indeed, we did explore the possibility of this multi-threaded design, and en ountered the above problems. While not impossible to over ome, the overall integration design was be oming lumsy and ompli ated. Fortunately, as is ommon with most event-based systems, both CORBA and T l provide hooks into their event pro essing that allow for external ontrol loops to be integrated. Both the CORBA perform work() all and the T l T l Servi eEvent() allow the intermixing of their event pro essing with other systems. Thus, to a ommodate mixed-intera tion tools, we have built a meta-level loop on top of these standard interfa es.4 However, we also allow this to be bypassed if no T l-side 4It is possible to build the meta-event-loop without the use of y le-burning polling by using the POSIX sele t() 10 pro re eive_request { } { variable TargetClass TargetIOR TargetMethod variable ClientClass ClientIOR RequestID variable MethodInArgsCount MethodInArgs variable MethodInArgsModes MethodInArgsTypes puts "$RequestID : $ClientIOR invoking $TargetMethod on $TargetIOR" puts " at time [ lo k format {%D %T}℄" puts " with $MethodInArgsCount params:" set i 0 forea h arg $MethodInArgs { set mode [lindex $MethodInArgsModes $i℄ set type [lindex $MethodInArgsTypes $i℄ puts " $arg ($mode,$type)" in r i } } Figure 3: T l request tra ing inter eptor example. intera tion is needed; this allows the ORB to be run most eÆ iently while still allowing T l-based inter eptors. Also note that none of this interferes with the ORB's threading model, whi h may be using multiple threads. 4 Status and Example We urrently have an implementedOrbish shell for both lient-side and server-side inter eption points, whi h are essentially identi al ex ept in where the ow of ontrol is managed. In pure lient CORBA appli ations, ontrol is generally kept within the appli ation ode, while with server appli ations the ORB itself is the point of ontrol, only evoking server obje ts when requests arrive. Figure 3 shows an example T l pro edure for the server-side re eive request inter eption point. This example pro edure simply prints out a tra e message, listing the request ID, the obje t IDs involved, the time of this invo ation, and the parameter values, modes, and types. Note that system all. This is an example of exa tly the type of low-level programming that we are trying to hide from the introspe tion tool developer. 11 Figure 4: CORBA server-side inter eptor GUI example. the lo k ommand is a built-in T l ommand that deals with time. Doing a similar tra e in C++ would require a ode listing mu h longer than a page in this paper. GUI interfa es on the inter eption points is similarly easy, though the ode is a bit longer due to simply onstru ting the GUI elements. Figure 4 shows a s reenshot of a simple logging tool built on top of our orbish framework. This simply shows a sequen e of server invo ations of a test server obje t that implements add, subtra t, multiply, and divide operations. The logging window shows the listing of the method name, arguments, argument types, and argument modes (in these ases, all plain input arguments). This window does not show all of the information available to the inter eptors, whi h is detailed in the previous se tion. We have implemented the server-side manipulation part of the Orbish framework, using the forwarding and the DII (Dynami Invo ation Interfa e). Currently, our DII inter eptor obje t is spe i to the appli ation obje t being inter epted, yet it is generi enough that it ould be automati ally generated from the appli ation obje t's IDL ode. We are in the pro ess of weighing the hoi e between writing a ompletely generi manipulation inter eptor that would use a CORBA interfa e repository versus the simpli ity of generating individual manipulation inter eptors. Using the interfa e repository and a run-time representation of the IDL interfa e may bring other re e tion-style bene ts other than just our manipulation inter eptors. 5 Related Work There is mu h related work in the area of runtime monitoring and manipulation of software systems, be ause this task has been around ever sin e the rst program needed debugging. We will hilight a few re ent examples. In [14℄, Tewksbury et al. des ribe the Eternal system, a CORBA-based system that inter epts low-level IIOP messages for the purposes of reating a highly fault-tolerant and on-line evolvable environment. Their purposes, whi h are not dire ted towards inspe ting and manipulating invo a12 tion arguments and other data, and the fa t that their work was begun mu h before the Portable Inter eptor standard began to be available, makes it natural for them to inter ept low-level messages. The ommer ial ORB of Iona In ., named Orbix(tm), has long in luded features for developers to inspe t and manipulate their appli ation obje ts [7℄. These features in lude lters and smart proxies, both whi h a t as intermediate inter eption points that an examine and modify the invo ation's input or output data. The main di eren e from our approa h is that these are vendorspe i , and must be programmed at a low level. The re ent interest in meta-obje t proto ols (e.g., [1, 9℄) and other me hanisms for manipulating the behavior of programs and programming languages is relevant to our work. These usually take a mu h broader approa h in that their goal is to provide me hanisms to program the way in whi h the OO languages reate and manipulate their run-time obje ts. Although examples that add fun tional behavior to an appli ation, su h as garbage olle tion or persisten e, are often used, these MOPs ould be used for su h things as inspe tion and manipulation. These approa hes generally assume the meta-programming tasks are to be done in the same programming (similar to the Java Re e tion API). The Byte-Code Engineering Library is an interesting and useful e ort, whi h provides an API to a full suite of Java byte ode manipulation me hanisms [3℄. It is straightforward to, for example, run preompiled Java lasses through a BCEL-based program that instruments all method alls for inspe tion purposes (manipulation ould also be done, using extensive Java Re e tion programming). Many other byte ode hange me hanisms are available. Similar to other related work, although the API o ers methods to manipulate the various elds in a Java lass stru ture, there is no attempt to make it any easier for the developer to produ e spe i tools for spe i needs. The writer of BCEL-based programs needs a deep understanding of Java lass les, lass loading, and even the JVM instru tion set. Aspe t-Oriented Programming [8℄: This model of programming is based on the idea that the software systems will be better o programmed by separately spe ifying the various soalled onerns and their relationships. The AOP will take are of weaving or omposing these on erns together to form a oherent system. Con erns in AOP model are implemented using what is alled aspe ts. An aspe t is a single modular unit that annot be en apsulated leanly in a generalized omponent (Pro edure or Obje t). Aspe ts tend not to be units of the systems fun tional de omposition, but rather to be properties that a e t the performan e or semanti s of the omponents of the system in systemi ways. In our proje t, we an identify one major on ern, whi h is the interospe tion. This on ern in not implemented via a single omponent but rather via many omponents (In our ase, we have lient inter eptor and server inter eptor. Of ourse we ould have implemented IOR inter eptor). One ould see the TCL omponent that we have implemented ( alled namespa e CorbaInter ept) as an aspe t implementing this on ern. This aspe t-if we might say soput together leanly what might have been s attered out a ross many omponents. Bean Markup Languege [15℄: Bean Markup Language (BML) an XML-based on guration language introdu ed mainly to be used with the JavaBean omponent model. The language is 13 designed to be dire tly exe utable in the sense that it will result in a running appli ation beingon gured as des ribed in the given BML s ript. The BML language is omposed of XML elementsthat an be used to des ribe reating new beans, a essing of existing beans, hanging beansproperties, binding of events from some beans to other beans as well as alling of arbitrary methodsin beans. BML an be used as an abstra t model for des ribing the stru ture of a omponent-basedappli ation.The only onne tion that I an think of between our proje t and BML is that BML provides auseful high-level textual abstra tion apturing the stru ture of omponent-based appli ations. OurTCL s ript somewhat does the same with the inter eption omponents by providing a textual way(TCL way) of inter epting and manipulating requests and responses as they ome and go.6 Con lusionThis paper has presented an approa h to providing a foundation that greatly redu es the e ort inonstru ting introspe tion and manipulation tools. The spe i framework in this paper is Orbish,a T l/Tk-based s ripting interfa e to the CORBA Portable Inter eptor spe i ation, along withextensions to allow for manipulation of CORBA invo ations and replies. Su h a foundation allowsappli ation developers to easily build ustomized introspe tion tools suited for their parti ularmaintenan e needs, and allows tool builders a framework from whi h to prototype possible larger,more robust tool behavior. We believe this approa h an be applied in many settings, and areurrently working on similar proje ts in the areas of Java lasses and Linux shared (dynami -link)libraries.In designing foundational introspe tion support into programming languages and frameworks,it has often been the ase that the designers have simply looked at the task at hand, be it loggingor debugging or dynami appli ations, and have not onsidered what might be the best generiapability that would support a wide variety of tools and apabilities.We have found this to be true as well with CORBA Portable Inter eptors. Rather than us-ing the opportunity to design fundamental fun tionality that would support many apabilities,the inter eptor standard was limited to \observation-only" a ess to CORBA messages, and toex eption-generating interferen e with normal messaging pro essing. If the inter eptor standardhad been given modi ation a ess to the messages, many more apabilities ould have been eas-ily built on top of them, su h as wrappers that glue disparate omponents together or wat h foranomalous onditions and \pat h up" results, or CORBA debuggers that ould manipulation valuesin order to understand more about what is happening.However, despite these limitations, o ering a highly exible, s ripting-language-based interfa eto the introspe tion and manipulation of CORBA appli ations will ease the onstru tion diÆ ultiesof these appli ations, espe ially in the ase of trying to integrate reused omponents into newenvironments. Not only will it enable omplex development tools to be onstru ted, but it willallow appli ation developers to reate their own spe ial-purpose tools for their urrent problem athand.We plan to ontinue developing our inter eptor-based framework, to in lude more apability of14 re e tion, and ultimately to support our own resear h into multiple-version exe ution for reliableomponent evolution, and other su h meta-programming ideas.REFERENCES[1℄ S. Chiba. A Metaobje t Proto ol for C++. In Pro eedings of the 1995 Conferen e on Obje t OrientedProgramming, Systems, Languages, and Appli ations (OOPSLA), pages 285{299, 1995.[2℄ J.E. Cook and J.A. Dage. Highly Reliable Upgrading of Components. In Pro eedings of the 21stInternational Conferen e on Software Engineering, pages 203{212, May 1999.[3℄ M. Dahm. Byte Code Engineering with the BCEL API. Te hni al Report B-17-98, Te hnologi alInstitute Free University of Berlin, April 2001.[4℄ S. Eisenba h and C. Sadler. Changing Java Programs. In Pro eedings of the 2001 International Con-feren e on Software Maintenan e, pages 479{487, November 2001.[5℄ D. Garlan, R. Allen, and J. O kerbloom. Ar hite tural Mismat h or Why it's Hard to Build SystemsOut of Existing Parts. In Pro eedings of the 17th International Conferen e on Software Engineering,pages 179{185. Asso iation for Computer Ma hinery, April 1995.[6℄ G. Hamilton, ed. JavaBeans API Spe i ation, 1.01. Te hni al report, Sun Mi rosystems, In ., 1997.[7℄ Iona. Orbix Programmer's Guide Java Edition. Te hni al report, Iona Te hnologies, In ., 2000. athttp://www.iona. om/do s/manuals/ orbix/33/html/orbix33 xx pguide/.[8℄ G. Ki zales, J. Lamping, A. Mendhekar, C. Maeda, C.V. Lopes, J.M. Loingtier, and J. Irwin. Aspe t-Oriented Programming. In Pro eedings of the 1997 European Conferen e on Obje t Oriented Program-ming (ECOOP), June 1997.[9℄ G.J. Ki zales, J. des Rivieres, and D.G. Bobrow. The Art of the Metaobje t Proto ol. MIT Press, 1991.[10℄ Obje t Management Group. CORBA Portable Inter eptor Spe i ation. January 2001.[11℄ OMG. The Common Obje t Request Broker: Ar hite ture and Spe i ation, v2.4.2. Te hni al Reportformal/01-02-01, Obje t Management Group, 2001.[12℄ D. B. Orr, R. W. Me klenburg, P. J. Hoogenboom, and J. Lepreau. Dynami Program Monitoring andTransformation Using the OMOS Obje t Server. Kluwer A ademi , Boston, Massa husetts, February1994.[13℄ J.K. Ousterhout. T l and the Tk Toolkit. Professional Computing Series. Addison-Wesley, Reading,MA, 1994.[14℄ L.A. Tewksbury, L.E. Moser, and P.M. Melliar-Smith. Live Upgrades of CORBA Appli ations UsingObe t Repli ation. In Pro eedings of the 2001 International Conferen e on Software Maintenan e, pages488{497, November 2001.[15℄ S. Weerawarana and M.J. Duftler. Bean Markup Language. Te hni al report, IBM AlphaWorks, 1999.at http://www.alphaworks.ibm. om/te h/bml.15